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METHOD AND APPARATUS FOR CENTRALIZING A CERTIFICATE REVOCATION 



LIST IN A CERTIFICATE AUTHORITY CLUSTER 



BACKGROUND OF THE INVENTION 
5 Field of the Invention 

The present invention relates to the field of digital 
certificates. More particularly, the present invention relates 
to the centralization of certificate revocation lists in 
certificate authority clusters. 

10 

Related Art 

Digital certificates are widely used over communication 
networks and in the field of electronic commerce for document 
and identity authentication purposes. In general, such digital 

15 certificates are used to certify the identity of an entity in 
the digital world, particularly as defined by the public key 
infrastructure (PKI) . In any PKI, a certificate authority (CA) 
is a trusted entity that issues, renews, and revokes 
certificates. An end entity (EE) is a person, router^ server, 

20 or other entity that uses a certificate to identify itself. 

To participate in a PKI, an end entity must enroll, or 
register, into the PKI system. The end entity typically 
initiates enrollment by giving the CA some form of 
25 identification and a newly generated public key in the form of 
a ^'certificate request.'' The CA uses the information provided 
to authenticate, or confirm the identity. In addition to 
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authenticating the end entity, the CA uses the public key to 
ensure ''proof of possession/' that is, as cryptographic 
evidence that the certificate request was signed by the holder 
of the corresponding private key. Finally, the CA issues a 
"'certificate" that is associated with the end entit/ s identity 
and its associated public key. The CA signs the certificate 
with the CA' s own private signing key. By signing, the CA is 
authorizing the identity of that particular certificate and 
public key. 



As digital certificates are issued and used, they often 
are either revoked for various reasons. Revocation can be 
defined as the removal of a certificate' s validity prior to its 
certificate expiration date. A typical example would be when 

15 an employee holding a private key on the part of a corporation 
leaves that corporation- In that case it would be necessary 
for certificates associated with that private key to be 
revoked. Otherwise, that person, or any other person holding 
the private key, with the proper access knowledge, could 

20 perform unauthorized transactions on the part of the 
corporation. 



Many other situations may require the placement of a 
certificate on the CRL. For example, each of the following 
25 cases illustrate situations involving revoked certificates: 
when the relationship between an issuing party and an 
organization is severed or suspended, an issuing authority 

SUN-P6043/ACM/LCH 2 



ceases to operate, there is suspected private key compromise, a 
certificate is no longer required by the client, etc. 

In other situations, digital certificates may be revoked 
5 or placed on hold pending some future event. In such a case, a 
user may have misplaced a private key, associated with a 
particular certificate, and is currently searching for it. 
Also, a user may have forgotten the password needed to access 
the private key. In that case, the associated digital 
r;i 10 certificate is revoked until the password issue is resolved. 
^ Additionally, a user may go on vacation, and requests that a 

St digital certificate associated with the user' s private key be 

revoked until the user' s return from vacation. 

D 15 A fundamental requirement of PKI is to maintain a path or 

chain of trust. It is therefore essential to have a mechanism 

3 by which digital certificates can be verified as to its 

validity. One solution amongst many standards in use today is 
the Certificate Revocation List (CRL) . The CRL is a published 
20 data structure that is periodically updated. The CRL contains 
a list of revoked certificate serial numbers. The CRL is time- 
stamped and digitally signed by the CA who issues the 
certificates, or other third party entities, such as a 
revocation service. CRLs are currently defined in the X.509 
25 standard and its various versions. 
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Prior Art Figure 1 depicts a communication system network 
100 that utilizes a digital certificate and a CRL. In system 
100^ a user terminal 104 may request via a network 108, a 
digital certificate from a CA 112. The CA 112 generates and 
5 issues the certificate, which is returned to the user terminal 
104- The user terminal 104 can then utilize the digital 
certificate to carry out transactions with another entity, such 
as, remote server 116. Such transactions may include financial 
transactions or any other transaction in which the identity of 
10 the user terminal 104 should be reliably authenticated* 

When user terminal 104 sends the digital certificate to 
the remote server 116, during verification of the chain of 
trust, the remote server 116 can inspect the digital 

15 certificate against a list of revoked certificates (the CRL) 
that is stored by the remote server 116. In the event remote 
server 115 has not obtained a recent CRL, one can be requested 
from the CA 112. The CA 112 then either generates a new CRL or 
sends the most recently generated CRL to the remote server 116. 

20 Remote server 116 can then determine whether or not the digital 
certificate sent by user terminal 104 is valid. Thus, remote 
server 116 can authenticate the user terminal 104 and determine 
whether or not to authorize a particular transaction at hand. 

25 To achieve greater scalability, a web server cluster that 

comprises a Certificate Authority is one solution for meeting 
the growing need for CA services. Figure 2 of the prior art 
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illustrates a cluster network CA 200. The CA cluster 200 is 
comprised of a plurality of clone CA servers, e.g. CA clone-1 
210, CA clone-2 210, on up to CA clone-n 230. Each of the CA 
clone servers is capable of conducting all the CA services, 
such as, certificate enrollment, certificate renewal, 
certificate revocation, publishing CRLs, etc. As such, each of 
the CA clone servers of the CA cluster 200 is capable of 
issuing certificates verified by the same CA signing 
certificate associated with the CA cluster 200. 



In the CA cluster 200, each of the CA clones maintain 
and manage an independent set of certificates. For example, 
the CA cluster 200 may manage up to 1000 certificates. The CA 
clone-1 210 may manage certificates with serial numbers between 

15 1 to 200. The CA clone-2 220 may manage certificates with 

serial numbers between 201 to 400, and so on. Finally, the CA 
clone~n 230 may manage certificates with serial numbers between 
801 to 1000. Each of the CA clone servers in the CA cluster 
200 perform all of the services associated with their assigned 

20 certificate serial numbers, including issuing certificates, 
renewing certificates, revoking certificates, etc. 



Further, the cluster feature of CA cluster 200 allows for 
scalability. In the first case, each of the CA clone servers 
25 can expand the number of certificates it issues and manages. 
For example, a new set of serial numbers can be issued to one 
or more CA clone servers in a CA cluster to service 
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certificates beyond serial number 1000. Secondly, additional 
CA clone servers can be added to service certificates beyond 
serial number 1000. Also^ CA clone servers may be taken off- 
line when demand for certificates may lessen, as long as the 
5 database information is carefully transferred to an on-line CA 
clone server for handling renewal and revocation. 

A load balancing server 250 is capable of intelligently 
distributing load across the CA cluster. Also, the load 
10 balancing server 250 can control routing of messages to the 

proper CA clone (e.g., CA clone 210, 220, on up to clone 230). 
Proper request distribution helps to achieve scalable and 
predictable cluster performance and functionality. 

15 In this cluster configuration, the CA cluster 200 appears 

as a single CA to the clients. As such, the CA cluster can 
have a virtual address. 

The CA cluster 200 configuration of Prior Art Figure 2 
20 has an associated CRL that contains a list of all the pertinent 
revoked certificates associated with CA cluster 200. In the 
prior art solution, each of the CA clones (e.g., 210, 220, on 
up to 230) maintains identical CRLs that pertain to all the 
revoked certificates in the CA cluster 200. For example, CA 
25 clone-1 contains a CRL-1 212, CA clone-2 contains a CRL-2 222, 
on up to CA clone-n which contains a CRL-n 232. Each CRL is 
not partitioned, where only the revoked certificates pertaining 
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to the particular clone containing the CRL is stored. Rather^ 
each CRL (e.g. CRLs 252, 212, 222, on up to 232) contains a 
complete list of revoked certificates associated with the CA 
cluster 200 • Maintenance of identical CRL lists in each of the 
5 servers in the CA cluster configuration is implemented in order 
to comply with the Internet X.509 standard that requires all 
CRLs to be complete. 

Further, maintenance of only partial CRLs that pertain 
10 only to certificates with serial numbers that are particular to 
each of the servers in the CA clone cluster would compromise 
the purpose of the CRL. For example, when a request for a CRL 
comes in from a third party remote server, such as remote 
server 116 of Prior Art Figure 1, the request could be 
15 distributed to any one of the servers in the CA cluster 200. 
Since each of the servers in the CA cluster 200 would only 
contain partial CRLs pertaining to certificates with serial 
numbers associated with the server servicing a CRL request, the 
CRL would be incomplete. A possible revoked certificate that 
20 is important to the requester would not be included in the 

partial CRL list. Therefore, it would be necessary to maintain 
identical CRLs at each of the servers in the CA cluster 200. 

However, maintenance of identical CRLs at each of the 
25 servers in the CA cluster 200 would limit increased scalability 
of the cluster. With increased number of entries in a CRL, 
increased processing is necessary to maintain each of the CRLs 
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in the CA cluster 200 to ensure their accuracy. Also, copying 
over key and certificate files^. along with other information 
pertaining to these files, such as configuration, is a manual 
process and can be time consuming and tedious. This increased 
computer processing wastes important central processing unit 
(CPU) resources at each of the CA clones in the CA cluster 200. 
Furthermore, duplicating the CRL at each server in CA cluster 
200 in a scalable environment wastes valuable memory resources, 
especially when the cluster becomes overly large. 

As digital certificates find wider use, the number of 
such certificates issued has increased dramatically. With this 
increase comes an associated increase in the number of entries 
in a Certificate Revocation List, Accordingly, a need exists 
to overcome the lack of scalability in producing multiple CRLs 
at CA clones. Also, a need exists to satisfy the Internet 
X.509 Public Key Infrastructure Certificate and CRL Profile 
(RFC 2459) communication standard that requires complete CRLs 
be maintained. 
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SUMMARY OF THE INVENTION 

Embodiments of the present invention disclose a method 
and system for centralizing a certificate revocation list (CRL) 
in a certificate authority cluster of servers, Also^ one 
5 embodiment of the present invention overcomes scalability 

issues that arise when maintaining and creating multiple CRLs 
in a CA cluster. Additionally, another embodiment of the 
present invention satisfies the X.509 Public Key Infrastructure 
Certificate and CRL Profile (RFC 2459) communication standard 
10 requiring maintenance of a complete CRL. 

These and other benefits and advantages of the present 
invention will no doubt become obvious to those of ordinary 
skill in the art after having read the following detailed 
15 description of the preferred embodiments which are illustrated 
in the various drawing figures. 

Specifically, one embodiment of the present invention 
describes a method and system for centralizing a single CRL in 

20 a certificate authority cluster. The certificate authority is 
comprised of a CA master server coupled to a plurality of CA 
clone servers that form a cluster of servers (CA cluster) . The 
CA master server provides a CRL merger service which maintains 
a single CRL for the CA cluster. Each of the CA clone servers 

25 in the CA cluster has the capability to provide CA services. 
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In one embodiment^ the present invention centralizes the 
CRL at a database accessed by the lightweight directory access 
protocol (LDAP) with Secure Sockets Layer (SSL) capability. 
The CA clone master maintains the single CRL for the CA cluster 
5 via a CRL merger service. In this way, each individual CA 
clone is alleviated from the need to generate CRLs that are 
complete in their own right. 

Each CA clone sends revocation information regarding a 
10 certificate upon a revocable event to the CA merger. Depending 
on the contents of the revocation information, upon receipt of 
the publication of a revocation certificate record regarding a 
certificate, the CA clone master through the CRL merger service 
adds or removes the serial number of the revoked certificate to 
15 the single CRL. In this way a single, centralized CRL is 
maintained for the entire CA cluster of servers. 



SUN-P6043/ACM/LCH 



10 



BRIEF DESCRIPTION OF THE DRAWINGS 

PRIOR ART Figure 1 is a block diagram of a public key 
infrastructure (PKI) system using digital certificates. 

PRIOR ART Figure 2 is a block diagram of a Certificate 
Authority (CA) cluster network creating and maintaining 
numerous identical Certificate Revocation Lists (CRLs) . 

Figure 3 is a logical block diagram of a CA clone master 
with CRL merger service capabilities^ in accordance with an 
embodiment of the present invention. 

Figure 4 illustrates a block diagram of an exemplary CA 
cluster network having a single, centralized CRL, in accordance 
with one embodiment of the present invention. 

Figure 5 is a flow diagram illustrating steps in a 
computer implemented method for centralizing a CRL in a CA 
cluster network, in accordance with an embodiment of the 
present invention . 
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DETAILED DESCRIPTION OF THE INVENTION 

Reference will now be made in detail to the preferred 
embodiments of the present invention, a method and system for 
centralizing a Certificate Revocation List (CRL) in a 
5 Certificate Authority (CA) cluster, examples of which are 

illustrated in the accompanying drawings. While the invention 
will be described in conjunction with the preferred 
embodiments, it will be understood that they are not intended 
to limit the invention to these embodiments. On the contrary, 
10 the invention is intended to cover alternatives, modifications 
and equivalents, which may be included within the spirit and 
scope of the invention as defined by the appended claims. 

Furthermore, in the following detailed description of the 
15 present invention, numerous specific details are set forth in 
order to provide a thorough understanding of the present 
invention. However, it will be recognized by one of ordinary 
skill in the art that the present invention may be practiced 
without these specific details. In other instances, well known 
20 methods, procedures, components, and circuits have not been 

described in detail as not to unnecessarily obscure aspects of 
the present invention. 

Notation and Nomenclature 
25 Some portions of the detailed descriptions which follow 

are presented in terms of procedures, steps, logic blocks, 
processing, and other symbolic representations of operations on 
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data bits that can be performed on computer memory. These 
descriptions and representations are the means used by those 
skilled in the data processing arts to most effectively convey 
the substance of their work to others skilled in the art. A 
procedure, computer executed step, logic block, process, etc., 
is here, and generally, conceived to be a self-consistent 
sequence of steps or instructions leading to a desired result. 
The steps are those requiring physical manipulations of 
physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals 
capable of being stored, transferred, combined, compared, and 
otherwise manipulated in a computer system. It has proven 
convenient at times, principally for reasons of common usage, 
to refer to these signals as bits, values, elements, symbols, 
characters, terms, numbers, or the like. 

It should be borne in mind, however, that all of these 
and similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied to 
these quantities. Unless specifically stated otherwise as 
apparent from the following discussions, it is appreciated that 
throughout the present invention, discussions utilizing terms 
such as ''accessing," or "processing," or "computing," or 
"translating," or "calculating," or "determining," or 
"'scrolling," or "displaying," or "recognizing," or the like, 
refer to the action and processes of a computer system, or 
similar electronic computing device, that manipulates and 
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transforms data represented as physical (electronic) quantities 
within the computer system's registers and memories into other 
data similarly represented as physical quantities within the 
computer system memories or registers or other such information 
5 storage, transmission or display devices. 

Referring now to Figure 3, embodiments of the present 
invention are comprised of computer-readable and computer- 
executable instructions which reside, for example, in computer- 
10 readable media of an electronic system, such as a CA clone 
master that manages the CRL merger service. Figure 3 is a 
block diagram of exemplary interior components of an exemplary 
electronic system 300 upon which embodiments of the present 
invention may be implemented. 

15 

Figure 3 illustrates circuitry of an exemplary electronic 
system 300. Exemplary electronic system 300 includes an 
internal address/data bus 320 for communicating information, a 
central processor 301 coupled with the bus 320 for processing 

20 information and instructions, a volatile memory 302 (e.g., 
random access memory (R7\M) , static RAM dynamic RAM, etc.) 
coupled with the bus 320 for storing information and 
instructions for the central processor 301, and a non-volatile 
memory 303 (e.g., read only memory (ROM), programmable ROM, 

25 flash memory, EPROM, EEPROM, etc.) coupled to the bus 320 for 
storing static information and instructions for the processor 
301. 
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With reference still to Figure 3, an optional signal 
Input/Output device 308 is coupled to bus 320 for providing a 
communication link between electronic system 100 and a network 
5 environment. As such, signal Input/Output (I/O) device 308 
enables the central processor unit 301 to communicate with or 
monitor other electronic systems or analog circuit blocks that 
are coupled to the electronic system 300 • The electronic 
system 300 is coupled to the network (e.g., the Internet) using 
10 the network connection, I/O device 308, such as an Ethernet 

C 

%!■ adapter coupling the electronic system 300 through a fire wall 

yi and/or a local network to the Internet. 

Qi An output mechanism may be provided in order to present 

□ 15 information at a display 305 or print output for the electronic 

system 300. Similarly, input devices such as a keyboard (not 
in shown) and a mouse (not shown) may be provided for the input of 

information to the electronic system 300, 

20 Electronic system 300 may also include various forms of 

disc storage 304 for storing large amounts of information, such 
as the list of certificates issued and the most recent 
Certificate Revocation List, as well as any other information 
that is required. 

25 

Ceisitraliziisig a Certificate Revocatiom List in a Certificate Authority Cluster 



This disclosure describes a method and apparatus for 
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centralizing a CRL in a CA cluster network. Embodiments of the 
present invention address the problem of a CA cluster network 
reaching a limit on its available CPU and memory resources in 
maintaining identical CRLs that are complete at each CA clone 
5 server. In addition, embodiments of the present invention 
satisfy the Internet X.509 Public Key Infrastructure 
Certificate and CRL Profile (RFC 2459) communication standard. 



m 



The method outlined in process 500 of Figure 5 in 
10 combination with Figure 4 provides a CRL that is compliant with 
the X.509 communication standard and maintains scalability 
features of a CA cluster network. Figure 5 is a flow diagram 
illustrating steps in a computer implemented method for 
centralizing a CRL in a CA cluster network, in accordance with 
15 one embodiment of the present invention. 

The present embodiment begins process 500 by creating a 
single CRL that is centralized. The CRL is associated with a 
CA cluster network in step 510. An exemplary CA cluster 

20 network 400 is illustrated in block form as shown in Figure 4. 
The CA cluster 400 is comprised of a plurality of clone CA 
servers, e.g. CA clone-1 410, CA clone-2 420, on up to CA 
clone-n 430, Further, a CA clone master server 450 manages and 
maintains the CRL associated with the CA cluster 400. The CA 

25 clone master server manages the CRL through a CRL merger 

service 470 located at the CA clone master 450. By separating 
the services involved with maintaining and managing the CA CRL 
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at a centralized location^ the resources for each of the CA 
clones (e.g.^ 410, 420, on up to 430) are more efficiently 
utilized to provide for CA services other than CRL management. 
This ensures increased scalability for the CA cluster^ and also 
5 is fully compliant with the Internet X.509 completeness 
requirement. 



The components of the CA cluster network are coupled via 
a suitable communication network (e.g. local area network, or 
10 wide area network, etc.)- In this way each of the CA clones 
can be located on a separate server computer in various 
geographical locations. 

Also, each of the CA clone servers is capable of 
15 conducting all the CA services, such as, certificate 

enrollment, certificate renewal, certificate revocation, etc. 
As such, each of the servers of the CA cluster 400 is capable 
of issuing certificates verified by the same CA signing 
certificate associated with the CA cluster 400. A load 
20 balancer {not shown) intelligently distributes new requests for 
certificates amongst the servers in CA cluster 4 00 in order to 
achieve proper load balancing and scalability of CA cluster 
400. 



25 In the CA cluster 400, each of the CA clones maintains 

and manages an independent set of certificates. For example, 
the CA cluster 400 may manage up to 1000 certificates at a 
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particular time. The CA clone-1 410 may manage certificates 
with serial numbers between 0 to 201. The CA clone-2 420 may 
manage certificates with serial numbers between 201 to 400^^ 
etc. The CA clone-n 430 may manage certificates with serial 
5 numbers between 801 to 1000. Each of the CA servers in the CA 
cluster 400 perform all of the services associated with their 
assigned certificate serial numbers, including issuing 
certificates;^ renewing certificates, revoking certificates, 
etc. 

10 

Further, the cluster feature of CA cluster 400 allows for 
J" scalability. In the first case, each of the CA clone servers 

'jf (e.g., 410, 420, on up to 430) can expand the number of 

"^"^ certificates it issues and manages. For example, a new set of 

y 15 serial numbers can be issued to one or more CA clone servers in 
^ a CA cluster to service certificates beyond serial number 1000. 

3 Secondly, additional CA clone servers can be added to service 

certificates beyond serial number 1000. Also, CA clone servers 
may be taken off-line when demand for certificates may lessen, 
20 as long as the database information is carefully transferred to 
an on-line CA clone server for handling renewal and revocation. 

Returning to Figure 5, the embodiment illustrated by 
process 500 in step 520 maintains a CRL 4 60, that is associated 
25 with the CA cluster network 400, by a CA merger service 450. 
The CRL 4 50 is associated with a directory server (not shown) . 
Communication between the CA clone master 450 and the directory 
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server occurs via a Lightweight Directory Access Protocol 
(LDAP) in one embodiment of the present invention. The CRL 
merger service 470 creates and maintains the CRL 460^ and 
responds to requests regarding the CRL 460 in order to 
centralize the CRL generation. In one embodiment, the CRL 
merger service 470 is a module located on the CA clone master 
450. Also, in another embodiment, the CA clone master 450 
which runs the CRL merger service 470 is a separate system 
independent of the CA clones in CA cluster network 400 in order 
to free up resources at each of the CA clone servers (e.g., 
410, 420, on up to 430) . 

By locating the CRL 4 60 in a centralized location, the 
X.509 communication standard is more easily satisfied. A 
single and complete CRL managed by the CA clone master 4 50 via 
the CRL merger service 470 satisfies the X,509 requirement that 
all CRLs be complete. 

Figure 4 discloses a CRL merger service 470 that runs 
separately from the CA clones (e.g., 410, 420, on up to 430) 
in the network 400. In this way, the burden of generating CRLs 
at each of the CA clones (e.g., 410, 420, on up to 430) is 
shifted from the CA clones to one location: the CA clone master 
450 running the CRL merger service 470. It is therefore 
essential, in one embodiment, to have the CRL merger 470 as a 
separate entity that can be potentially run on a separate 
machine . 



SUN-P6043/ACM/LCH 



19 



The CRL merger service 470 of Figure 4 is focused solely 
on creating and maintaining the CRL 4 60. In this way, the CA 
clone master 450 running the CRL merger service 470 is not 
5 burdened with other unnecessary connections or services. For 
example, in one embodiment of the present invention ^ the CRL 
merger service 470 maintains a database via a Lightweight 
Directory Access Protocol (LDAP) . In one embodiment, the CA 
clone master 450 communicates with the directory server (not 
10 shown) associated with the CRL 4 60 via LDAP that supports 
0 Secure Sockets Layer (SSL) . The LDAP database is ultimately 

III where revoked certification records and the CRL 4 60 are stored 

fij In another embodiment, the CRL merger service 470 performs its 

m functions through a servlet. The servlet could be located at 

n 15 the CA master 450 of Figure 4. 

\ " 

J The CRL merger service 470 of Figure 4 does not actively 

seek out revoked certificates from each of the CA clones in CA 
cluster 4 00. Instead, a revocation event at any of the CA 

20 clones triggers the information regarding the revoked 

certificate to be sent directly to the CA clone master 450 and 
the CRL merger service 470. Thus, the CA clone handling the 
certificate associated with the revocation event initiates 
communication with the CA clone master 450 in order to notify 

25 the CRL merger service 470 of Figure 4 of the revocation event 
In this way, the CA clone sends revocation information, 
associated with a certificate, to the CRL merger service 470. 
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The revocation information is in the form of a revocation 
certificate record in one embodiment. 

Referring back to Figure 5^ the embodiment showing 
5 process 500 illustrates the CRL merger service 470 
communicating with the CA clone handling the revoked 
certificate. In step 530^ the present embodiment receives the 
revocation information (e.g., notification of a revocation 
certificate record) from the CA clone that the certificate in 
10 question has been revoked and should be placed on the CRL 4 60. 

It is important to note, that the communication between 
the CRL merger service 470 and the CA clone handling the 
certificate associated with the revocation event includes all 

15 messages relating to the service provided in maintaining a CRL 
4 60. This includes revocation events that not only put 
certificates onto the CRL 4 60^ but also removes the certificate 
from the CRL 460. In other words, the revocation event may 
trigger the CA clone handling the event to communicate with the 

20 CRL merger service 470 in order to handle revoked or unrevoked 
certificates^ and on-hold or off-hold certificates. 

In step 540 of Figure 5^ the embodiment illustrating 
process 500 performs the necessary action in relation to the 
25 revocation information (e.g., publication of the revocation 
certificate record) and the associated revocation event. For 
example, if the revocation information indicates the revocation 
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event revokes a certificate, the CRL merger service 470 will 
add the serial number of the revoked certificate to the CRL 
460. If the revocation information indicates the revocation 
event unrevokes a certificate^ then the CRL merger service 470 
5 will remove the serial number of a revoked certificate, that 
previously was included in the CRL 460, from the CRL 4 60. 

In addition, certain certificates may be placed on the 
CRL 460 temporarily, and are revoked certificates pending some 
10 future event. These certificates are effectively on-hold until 
# further notice. This may address certificates whose keys are 

Ill not stolen or compromised, but possibly just misplaced. In 

f!j that case, if the revocation information pertaining to a 

S! revocation event indicates that the certificate is on-hold, the 

r| 15 CRL merger service 470 will add the serial number of the on- 

hold certificate to the CRL 460. Also, if the revocation 
^1 information pertaining to a revocation event indicates that the 

certificate is off-hold (e.g., the certificate has been found 
and is un compromised) , then the CRL merger service 470 will 
20 remove the serial number of the certificate from the CRL 4 60. 

The respective CA clones and the CRL merger service 470 
of Figure 4 communicate over a secure communication channel, in 
one embodiment of the present invention. In other words, the 
25 protocol used for transmitting certificate information from CA 
clones to their CA merger 470 is through a secure protocol over 
a secure communication channel. 
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In another embodiment of the present invention^ the CA 
clones conducts secure sockets layer (SSL) client 
authentication with the CRL merger service 470 over the secure 
5 communication channel before any communication is conducted 

between the respective CA clone and the CRL merger service 470. 
Those skilled in the art understand that other well known 
authentication methods can be utilized with embodiments of the 
present invention. 

10 

^1 Referring back to CA cluster network 400 in Figure 4^ 

If each of the CA clones (e.g., 410, 420, on up to 430) no longer 

^jf generate a separate and complete CRL. Instead, whenever there 

Gi is a revocation event, the CA clones handling the revocation 

0 15 event generates the necessary revocation information regarding 
'^^^ a particular certificate to be sent to the CRL merger service 

3 470. In other words, the CA clone publishes a revocation 

notice regarding a particular certificate record that is 
received by the CRL merger service 470. The CRL merger service 
20 470 then publishes or places the serial number of the revoked 
certificate on the CRL 460 database. In this way, important 
CPU and memory resources are liberated from generating and 
maintaining the separate and complete CRLs at each of the CA 
clones in CA cluster network 400. As such, since the 
25 generation of and services provided for a single CRL 460 is 

centrally located in a CA clone master 450 whose sole operation 
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is to run and manage the CRL merger service 470, the CA cluster 
network 400 is fully scalable. 



In addition, each individual CA clone in exemplary CA 
5 cluster 400 has the ability to detect any missed publication of 
revocation certification records, or revocation notice, in 
accordance with one embodiment of the present invention. These 
missed publications indicate the revocation notice was not 
received by the CRL merger service 470, and more importantly, 
Q 10 the certificate was not put onto the CRL 4 60 database. In this 
,Q manner, the revocation certificate record can be periodically 

HI resent by the CA clone until the CRL merger 470 receives the 

revocation certificate record, and publishes the record by 
putting the serial number of the revoked certificate into the 
y 15 CRL 4 60 database. 

p In another embodiment, when a CA clone in the CA cluster 

network 400 is restarted, the CA clone reads from a reliable 
resource that indicates which revoked certificates were 
20 unpublished. In this way, the CA clone can initiate a process 
whereby unpublished revocation certificate records will be 
resent by the CA clone to the CRL merger service 470 for 
publication. In one embodiment, publishing records are kept in 
the certification record itself, 

25 

In another embodiment of the present invention, if CRL 
merger service 470 is restarted, the CRL merger service 470 
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does not need to initiate any communication with the CA clones 
in the CA cluster network 400 of Figure 4. During the shutdown 
period, the CA clones will continue to send revocation 
certificate records to the CRL merger service 470 of Figure 4. 
5 Since all the CA clones know exactly which records were 

received and which records were not received by the CRL merger 
service 470, attempts will be made continuously made until, 
either, the CA clone has been shut down, or the CRL merger 
service 470 is up and running again. This will continue until 
10 the revocation certificate record is successfully received by 

O 

m the CRL merger service 470 and the record is published in the 

CRL 460 database. 

'i 

■■ j?'-^ 

CB In addition, each of the CA clones should remember which 

Q 15 last publication of a revocation notice, revocation certificate 
H record, was successful. As such, all unpublished revocation 

Q certificate records will be kept in memory (e.g., cache memory) 

for retransmission. 

20 To avoid searching through the entire CRL 4 60 database 

for unpublished revocation certificate records, under graceful 
shutdown of the CRL merger service 470, the CA clone can be 
allowed to store its unpublished revocation certificate 
records, which are stored in cache memory, to a more permanent 

25 storage location. 
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In still another embodiment of the present invention, a 
CA can change configuration from a self-sufficient (CRL 
generating) CA into a CA clone, such as those illustrated in 
Figure 4. The CA clone relies on a CRL merger service (e.g., 
5 CRL merger service 470) to generate the CRL 460. Also, the 
reverse is also possible, where a CA clone can change 
configuration to a self-sufficient CA. This is most useful 
when in retrofitting from a single CA environment to a multiple 
cloned CA cluster environment. In that case the original 
10 single CA needs to be reconfigured into a CA clone. A 
,0 mechanism is needed to search through its database for 

^ unpublished revocation certificate records and resend them to 

^JJ the CA clone master running the CRL merger service (e.g., 

merger service 470) . 

S 15 

Those skilled in the art will recognize that the present 
3 invention has been described in terms of exemplary embodiments 

based upon use of a programmed processor. However, the 
invention should not be so limited, since the present invention 

20 could be implemented using hardware component equivalents such 
as special purpose hardware and/or dedicated processors which 
are equivalents to the invention as described and claimed. 
Similarly, general purpose computers, microprocessor based 
computers, micro-controllers, optical computers, analog 

25 computers, dedicated processors and/or dedicated hard wired 
logic may be used to construct alternative equivalent 
embodiments of the present invention. 
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Those skilled in the art will appreciate that the program 
steps used to implernent the embodiments described above can be 
implemented using disc storage as well as other forms of 
5 storage including Read Only Memory (ROM) devices, Random access 
Memory (RAM) devices; optical storage elements, magnetic 
storage elements, magneto-optimal storage elements, flash 
memory, core memory and/or other equivalent storage 
technologies without departing from the present invention . 
10 Such alternative storage devices should be considered 
equivalents . 

While the methods of embodiments illustrated in process 
500 show specific sequences and quantity of steps, the present 

15 invention is suitable to alternative embodiments. For example, 
not all the steps provided for in the method are required for 
the present invention. Furthermore, additional steps can be 
added to the steps presented in the present embodiment. 
Likewise, the sequences of steps can be modified depending upon 

20 the application. 



Embodiments of the present invention, centralizing a 
Certificate Revocation List in a Certificate Authority cluster 
network, is thus described. While the present invention has 
25 been described in particular embodiments, it should be 

appreciated that the present invention should not be construed 
as limited by such embodiments, but rather construed according 

SUN-P6043/ACM/LCH 27 



to the below claims. 
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